In conventional software applications, a user typically interacts with the application according to one of several methods in order to instruct the software application to carry out an operation or a series of operations on behalf of the user. The user either sends commands to the application through a command line interface, or interacts with the application through a menu-driven interface.
The first model requires the user to somehow know or learn the command language specific to the application. An alternative would be for the user to send detailed written instructions to the application, in which case the application parses the detailed text to derive significant meaning in order to carry out the desired operations on behalf of the user. This approach may be burdensome for the user and the application, and is also prone to errors.
With the widespread usage of graphical user interfaces (GUIs) on personal computers and other computer-based systems, users have become used to the second model of interaction, namely menu interfaces provided by applications. In such a case, the user chooses a particular application to use, and by selecting from choices, or commands, in hierarchical menus provided by the particular application, the user instructs the application to provide the desired service. This model then requires the user to select an application to use, to which the application responds with a set of top level menu choices. Each subsequent choice by the user leads to a display of additional menu or sub-menu choices until the desired command or action is reached.
Often, users require remote access to such applications from a remote location via a network interconnection. Remote access to applications is achievable in a variety of forms, including dialup modem, broadband, virtual private networks (VPNs), wireless, etc. Such remote access forms typically include a messaging system for transport of data to and from the application. Messaging systems provide mechanisms to enable transport of various types and formats of messages between multiple users and applications. A user typically employs a device operable in the format or protocol expected by the messaging system. Primitive messaging systems include paper mail and manually switched voice networks, involving a human operator to manually carry a hardcopy or connect a circuit. Modern communication systems include networks such as the legacy circuit switched voice telephone network, affectionately known as the Plain Old Telephone System (POTS), wireless cellular networks, broadband hybrid fiber/coax networks, the aggregation of packet switched public access interconnections known as the Internet, and packet-switched voice operating over the Internet generally known as Voice over IP (VoIP). With the wide penetration of Internet connectivity, mobile cellular phones, and other similar means of communication, various interpersonal messaging systems have gained widespread popularity and usage. Such messaging systems include email, voicemail, short messaging service (SMS), instant messaging (IM), paging, enhanced messaging service (EMS), multimedia messaging service (MMS) and others. One common aspect of such conventional messaging systems, however, is that each discrete messaging unit, or data element, is atomic. Typically aggregated atomic messaging units may be meaningful such that the recipient correlates, or aggregates, the multiple atomic message units for this purpose.
In a conventional interactive voice response messaging infrastructure, users employ user devices to communicate, or interact with an application via a sequence of actions over the course of a session. In a typical session, the user and the application exchange a set of requests and responses. The user initiates the typical session with a particular application, usually with a telephone call to a telephone number corresponding to the application. The application responds with a conventional acknowledgement message, usually an initial voice menu prompt. The user then answers the prompt with another action, typically specifying one of the options proposed by the prompt. The application maintains a state, or context with the user, indicative of the aggregate responses by the user. An exchange of interactions continues until the user navigates the hierarchy of menu options to the desired task, option, or response, thereby completing the session.
Communication systems employ connection oriented or connectionless transport mechanisms. Connection oriented mechanisms, such as Asynchronous Transfer Mode (ATM), for example, dedicate an enumerable endpoint, such as a port, to a transaction or session between communicating entities. Messages follow an ordered sequence between the endpoints, in which each endpoint knows the complementary endpoint and the arrival order mirrors the transmission order. Accordingly, a receiver in a connection oriented mechanism examines the endpoint and receipt sequence of the messages to ascertain the context of each message within a session.
Conversely, a connectionless transport mechanism employs atomic message units which impart little or no context information. A connectionless mechanism, such as the User Datagram Protocol (UDP) over the Internet Protocol (IP) does not necessarily dedicate a physical port or enumerable endpoint to a particular session. Further, a connectionless mechanism provides no guarantees of arrival sequencing, since routing paths for messages may follow different paths, even in the same session. Accordingly, in a connectionless transport infrastructure, session context information is encapsulated in the messages or message headers to identify message sequence, origin, destination, and other context enabling information. Accordingly, a conventional receiver may properly aggregate the set of messages defining a session.
In a typical conventional infrastructure, a protocol identifies the mechanism as connectionless or connection oriented. Either a routing component or the application itself, therefore, maintains the state of the user session, such as the point of progression along the menu hierarchy. However, each individual message in the session is atomic. A menu selection response from a user, for example, is not significant without correlation to the menu options to which it responds. In a typical conventional voice response network, such as the legacy voice telephone network, the connection remains dedicated to a voice session. The dedicated connection terminates in a port or other identifiable endpoint to which the application is responsive. Accordingly, the application maintains the session context by a reference to the open, dedicated connection line since the conventional voice infrastructure assumes such a dedicated connection (port) between endpoints.
Typically, the applications employ a state corresponding to each user to identify the context of a particular session based on the previous informational items or actions such as messages exchanged during that session. In an application including state based aspects as a menu driven interface, the state identifies a current position in the traversal of the menu hierarchy. Other aspects of the application typically depend on some type of state information. In a connectionless protocol, such as HTTP, for example, message attributes may contribute to a mechanism for identifying and aggregating atomic message units as part of a contiguous session.
On the World Wide Web, for example, the HTTP request/response protocol model is based on a single round trip interaction, where the client makes a request of the server and the server responds such that no state information is maintained between interactions. Minimal state information can be imposed on this model by taking advantage of a client-stored session id (cookie). Client/Server sharing of this conventional session identifier allows context to be maintained throughout multiple interactions without affecting the simplicity of a single round trip interaction.